…Group (RunDKG)

Completes the real-cgo INTERACTIVE signing end-to-end test: a full FROST DKG that
PERSISTS a key group (RunDKG), followed by an interactive ROAST signing round
driven through the engine's interactive session API (DeriveInteractiveAttemptContext
-> InteractiveSessionOpen -> InteractiveRound1 -> NewSigningPackage ->
InteractiveRound2 -> InteractiveAggregate) with real frost-secp256k1-tr crypto.

It fills the gap in real-cgo coverage:
- _WithLinkedSigner proves the real crypto over the LOW-LEVEL Sign/Aggregate API
  (fed KeyPackage bytes directly);
- the fake-engine runner suite proves the Go-side orchestration without crypto.
This is the missing combination - the interactive session API the runner uses,
with real crypto - the prerequisite toward coarse-path retirement.

THE keyGroup GLUE = RunDKG. InteractiveSessionOpen resolves the signing key by a
keyGroup IDENTIFIER (engine-internal persisted material), not KeyPackage bytes, so
the low-level DKG result the test holds as bytes is not loadable as an interactive
keyGroup. RunDKG runs the full DKG, persists the result, and returns the keyGroup
the interactive (and coarse) signing path resolves - the same flow production uses
(the wallet runs DKG, gets a keyGroup, then signs).

Correctness is proven by the engine's SUCCESSFUL InteractiveAggregate: FROST
validates the shares and the aggregate internally, so a non-error 64-byte BIP-340
signature is a valid threshold signature over the message under the keyGroup's
group key. The one remaining nicety, an ADDITIONAL external schnorr.Verify, is
intentionally omitted: the engine exposes no keyGroup -> group-pubkey accessor
(RunDKG returns only the keyGroup id), so external verification would need a new
engine API. The e2e itself is complete via the internal validation.

Skip-guarded for absent linked tbtc-signer FFI symbols, so it is inert in CI builds
that do not link the Rust signer and runs only where the lib is present. Verifiable
in this env (no lib): cgo build/vet + gofmt clean and a clean SKIP; the DKG and
interactive round run only where the lib is linked.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…old)

Codex review fold on #4097. RunDKG persists the DKG result in the signer's
encrypted state, so a LINKED signer environment needs a state encryption key and
an isolated state path - which the existing _WithLinkedSigner test did not need
because its low-level Part1/2/3 DKG does not persist. Without them this e2e fails
before signing (TBTC_SIGNER_STATE_ENCRYPTION_KEY_HEX missing), and a shared/default
state path plus the fixed session id makes reruns conflict.

Set both before RunDKG: a deterministic 32-byte test encryption key, and a fresh
TBTC_SIGNER_STATE_PATH under t.TempDir() so each run starts from clean state. This
makes the test self-contained in a linked environment (no external state setup,
rerunnable). Still skips cleanly when the FFI symbols are absent.

Verified: cgo build/vet + gofmt clean; the test still runs and SKIPS cleanly
without the Rust lib.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>